Rewrite TmdbProvider to remove external lib dependency#2800
Conversation
As a side-effect, this also removes all gson usage from extractors and uses AppUtils methods, because gson was only an implicit dependency from the external tmdb library.
|
Will this remove all instances of gson? Because I think many extensions are using gson. |
gson was never officially supported, extensions should never have been using it. There is also no way to actually deprecate this so there is no way to fully communicate this. In order to facilitate eventual jackson -> kotlinx serialization, extensions should also first be using Jackson/AppUtils methods to make it easier. There really isnt a better way to communicate it. I dont know if this fully breaks extensions that uses gson or not, but IMO even if so the outcome would eventually be the same, they either break and have to migrate now or do so later. No official example or documentation said to use gson ever, so there was always the correct alternative. Will do what you want to do with this though. Again not certain if it breaks existing by removing the implicit dependency here though. |
"gson was never officially supported", Yes but extension developers sure do love using it. I am uncomfortable breaking the CI/CD of like half the extensions overnight without warning. https://github.com/search?q=repo%3Aphisher98%2Fcloudstream-extensions-phisher%20gson&type=code |
So then how do we even communicate it will be removed? If we keep it more and more usage will keep being added as well. We cant exactly deprecate it either. But I can add it back as an explicit dependency if you want? Still don't really like that by using this lib we accidentally had an implicit dependency causing a diversion in what should be used. But your right we probably should do this a little different then sudden removal. Not sure exactly best route though. |
|
Why dont we just communicate the best we can and remove it in 1-2 months? I plan to have the majority of my current efforts finished within the time frame, so want to push it fairly quickly if possible. But I dont think we need to keep it for a long time. We can't really follow a "deprecation" schedule for this and alternative has always existed. |
For this pull request, an explicit dependency would be best. However, for future development I think an issue on each repository should at least be a start. We can not communicate this over the deprecated API, but we can try to figure out the affected developers. Otherwise we might have to make a custom lint to warn about this. However, I am unsure if this would be possible for this usecase. |
|
Absolutely fair. A lint rule is actually what I was also thinking to facilitate jackson migration as well. |
2 participants
As a side-effect, this also removes all gson usage from extractors and uses AppUtils methods, because gson was only an implicit dependency from the external tmdb library.